Hello,

Je viens vous faire un premier retour sur votre article. Dans un premier temps, je trouve qu'il est clair et les références sont très précises. Malheureusement, je suis obligé de trouver la petite bête noire. J'ai principalement deux remarques :

L’organisation des paragraphes pourrait être plus pertinente. On explique en détails les erreurs (codes puants) puis on revient dessus en expliquant la solution possible. la syntaxe est légèrement lourde et répétitive. De plus, Il faut attendre la proposition de solution pour avoir des exemples de code smells. Cela faciliterait la compréhension d’en avoir dès la présentation des erreurs puante.

Deuxièmement, il manque des sources dans la correction de bug par exemple pour “duplicated code” tu dis “le mieux est de mesurer le pourcentage de lignes dupliquées dans le logiciel”, cependant ou est -il décrit que cette méthode est la meilleure ? Il n’y a pas de source pour prouver cette méthode et dire que c’est la meilleure n’est pas objectif si aucun article scientifique le prouve (Règle 2 : neutralité de point de vue). Ou encore dans la correction de bug BLOB “En plus d'être totalement inélégante ”, c’est trop objectif (ce n'est pas un fait que donner trop d'importance à une méthode est inélégant, règle 2).

Pour résumer, je dirais que les points noirs sont à mon avis le manque d'objectivité sur certains points, le manque de source dans les corrections de bug et l'enchainement des définitions des codes puants et des corrections.

Il n'y a pas énormément de faute dans l'article rien qui pique les yeux :

dans moyen de détection “a adopter” -> à
un point solitaire dans "Duplicated code. est" -> Duplicated code est
il manque un s dans l'exemple d'erreur Feature Envy "Le plus souvent ces appels sont fait" -> faits
pareil dans blob "un nombre d'appel" -> appels
"la détection est assuré" -> assurée

J'espère que ma contribution vous aidera.

Abdelrhamane BENHAMMOU.

5 janvier 2016 à 10:02 (CET)Partitum scire (discuter) 5 janvier 2016 à 10:02 (CET) Bonjour,[répondre]

je suis Yassine Badache, et je vais également vous aider afin d'écrire un article éligible et de meilleure qualité par des commentaires objectifs et des remarques neutres.

Codes Smells[modifier le code]

=> Codes Smells devrait à mon sens s'écrire Code smells dans la mesure où Smells n'est pas un nom propre et que c'est un terme anglais, donc le premier terme ne s'accorde pas.
=> Merci beaucoup c'est corrigé.
=> La documentation et les références sont excessivement claires et précises.

Les parties sont toutes ordonnées de la même manière (explication, exemple, explication technique, solutions existantes par exemple pour la section 2.2), ce qui est une bonne chose et conserve une certaine cohérence le long de l'article.

En génie logiciel, les codes Smells ou mauvaises odeurs, sont des mauvaises pratiques de conception logicielle qui conduisent à l'apparition de défauts. Ces défauts sont souvent issus de mauvais choix d'implémentations ou de conceptions et conduisent à une complexification du code source et de la maintenance et évolutivité de celui-ci. Afin de corriger un code smell, il est nécessaire de procéder à une réfactorisation du code source, c'est à dire modifier le code sans en altérer son comportement.

==> Réfactorisation -> Refactorisation
=> OK, les mots "réfactorisation" ont été anéantis.

Exemples de codes smells[modifier le code]

A la manière des patrons de conceptions, de nombreux exemples de code smells ont été répertoriés et décris dans la littérature scientifique.

==> Décris -> Décrits

Martin Fowler en a notamment répertorié des dizaines ainsi que la réfactorisation à adopter^[1].

Duplicated Code^[2][modifier le code]

Duplicated code. est un exemple de code smell classique. Il s'agit de trouver la même portion de code à plusieurs endroits d'une application.

=> Essayez de ne pas commencer vos paragraphes de section par leur nom, car ce phénomène apporte une sorte de personnification du procédé décrit (1.1.1 Duplicated code est [...]). Ce serait comme dire : Segmentation Fault est une exception survenant [...].

Le code dupliqué peut se situer dans une même classe, au sein de méthodes différentes, ou dans des classes différentes.

Feature Envy^[3][modifier le code]

Feature Envy décrit une méthode qui fait de nombreux appels à des méthodes d'autres classes. Le plus souvent ces appels sont fait à des "getters"/"accesseurs" par besoin de données.

C'est le signe que la méthode se trouve probablement dans la mauvaise classe.

BLOB[modifier le code]

Aussi connu sous le nom de God Class ou Winnebago, le Blob est une classe ayant trop de responsabilités au sein du logiciel.

Cela se manifeste par un trop grand nombre d'attributs et de dépendances aux classes data, ainsi qu'un nombre d'appel de ces méthodes par les classes extérieur très important.

=> Pour clarifier un peu le texte, essayez de mettre les termes anglais de ce genre en italique, afin qu'ils ressortent -> classes data. ==> Classes extérieur -> Classes extérieures

Long Parameter List^[4][modifier le code]

Long Parameter List est une erreur hérité des débuts de la programmation, avant l'arrivée de l'orienté objet. Chaque fonction nécessitait toute une série de paramètres, qu'il était préférable d'utiliser à la place des variables globales.

==> Hérité -> Héritée

Mais aujourd'hui et depuis l'arrivée des langages orientés objets, la situation a évoluée et le surnombre de paramètres ne fait que nuire à la lisibilité et la compréhension. Cela complique également l'utilisation et la réfactorisation du code.

==> A évoluée -> A évolué

Long Method^[5][modifier le code]

L'implémentation de longues méthodes est un problème récurent chez les développeurs débutants. Il s'agit de rendre les méthodes inutilement longues et complexes quand il est possible de les décomposer.

Cette décomposition en plus d'améliorer la lisibilité et la compréhension d'un code, permet de simplifier la réfactorisation par la suite. On la caractérise souvent par l'utilisation d'un trop grand nombre de paramètres internes, de boucles ou conditions ainsi que de valeurs de retour.

Large Class^[6][modifier le code]

Large Class décrit simplement le cas d'une classe possédant beaucoup de variables. Ce genre de situation induit parfois une utilisation séparées des variables et conduit le plus souvent vers de la duplication de code.

==> Une utilisation séparées -> Une utilisation séparée

Détection et correction de codes smells[modifier le code]

Moyens de détection[modifier le code]

Pour chaque code Smell, il existe des moyens de détection plus ou moins mathématiques ainsi que des pratiques permettant de corriger ou même éviter l'erreur. Pour chacun des six codes Smells précédents, voici la méthodologie de correction ainsi que le moyen de détection a adopter.

Duplicated Code[modifier le code]

Pour détecter le Smell Duplicated Code (code dupliqué littéralement), le mieux est de mesurer le pourcentage de lignes dupliquées dans le logiciel. Cela peut paraître assez simple d'un premier abord, mais un morceau de code peut être dupliquée de différentes manières.

==> Un morceau de code peut être dupliqué -> dupliquée

La détection du duplicata exact est trivial, mais dans certains cas, il faut aussi être capable de gérer le renommage ou l'alias.

==> Trivial -> Triviale

Par exemple en JAVA : => Java, et pas JAVA !

Integer var = 5;
String str = String.valueof(var);

est la duplication de code de :

Integer nombre = 5;
String chaine = String.valueof(nombre);

Si tel est le cas, il faut donc que l'algorithme de détection teste toutes les possibilités de renommage pour être bien certain de ne pas manquer un doublon de code. De plus, il est tout à fait possible que la duplication de code ai été modifiée légèrement.

==> Ai -> Ait

Si nous reprenons notre exemple, il faudrait aussi prendre en compte les cas suivants :

=> Et idem pour "nous", ça n'est pas vous qui présentez un article (3, Nous vous proposons une liste non exhaustive des principaux outils existants.).

Integer var = 5;
// Du code ne modifiant pas var...
String str = String.valueof(var);

Dans d'autres cas, on peut avoir deux algorithmes différents faisant le même travail. Dans un tel cas, on sélectionne l'algorithme le plus optimisé et on l'utilise pour les deux appels.

=> Essayez d'éviter les "on". Il est souvent possible de tourner la phrase de manière plus objective. Exemple en 2.1.1: Dans un tel cas, on sélectionne l'algorithme le plus optimisé et on l'utilise pour les deux appels. peut devenir Le cas échéant, l'algorithme le plus optimisé est sélectionné et utilisé pour les deux appels.

Cette erreur est souvent commise par les débutants suite à des abus de copier/coller. En plus d'augmenter sensiblement la taille du code source, elle engendre également des problèmes lors de la maintenance.
Pour corriger ce problème, il faut créer une méthode effectuant le code dupliquée et appeler cette nouvelle méthode à la place des doublons.

==> Effectuant le code dupliquée -> dupliqué. (Et cette phrase n'a pas de sens).

Enfin, il est possible de l'éviter en s'imposant les bonnes pratiques de développement suivantes :

Factoriser son code le plus possible (et dès que possible).
Travailler en TDD, Test Driven Development.

Feature Envy[modifier le code]

Le Smell Feature Envy (caractéristiques jalouses littéralement) survient dans une classe quand une méthode est plus intéressée par les membres (attributs et méthodes) d'une autre classe que les siens.
Pour corriger ce genre de problème au sein d'une classe vous pouvez :

=> Idem pour les pronoms "vous", que l'on remplacera aisément pas du passif.

Déplacer une méthode d'une classe dans une autre si elle utilise plus les données de celle-ci que les siennes.

Par exemple, dans la classe Rectangle, la méthode perimetre() peut être totalement déplacée dans la classe AutreClasse.

public class Rectangle {

   ...

   public Double perimetre() {
        return 2 * AutreClasse.largeur + 2 * AutreClasse.longueur;
   }

}

Déplacer une partie d'une méthode dans une autre si elle accède aux données d'une autre classe plus que les siennes. Même principe avec une méthode accédant aux données de plusieurs classes.

Par exemple, dans la classe bateau, la méthode preparer_bateau() utilise plus d'appels de méthodes de la classe SPI que ses propres méthodes.

public class Bateau {

   private SPI spi;
   private Reserve reserve;

   ...

   public void preparer_bateau() {
        this.laver();
        this.verifier_coque();
        reserve.verifier_provisions();
        spi.regler_hauteur();
        spi.regler_largeur();
        spi.verifier_voile();
   }

}

La correction adaptée serait donc de créer une méthode dans SPI regroupant les trois appels et de appeler cette nouvelle méthode dans preparer_bateau().

==> De appeler -> d'appeler

Pour détecter le code Smell Feature Envy, il faut être capable de localiser les méthodes utilisant trop les méthodes d'une classe extérieure.
Pour cela, il faut mesurer la force de couplages qu'à les méthodes d'une classe avec les autres méthodes ou données de classes extérieures.

==> Force de couplages -> Couplage

Lanza et Marinescu propose une formule conditionnelle de détection basée sur des métriques^[7] :

==> Lanza et Marinescu propose -> Proposent

$FDP\leq 5\land ATFD>5\land LAA<\left({\frac {1}{3}}\right)$

=> * Les formules sont bien expliquées et pertinentes quant au contexte.

Avec :

5, une valeur fixée et expliquée dans leur ouvrage.
LAA (Locality of Attribute Accesses) qui représente la proportion de méthodes de la classe utilisant accédant à plus d'attributs de classes extérieures qu'à ses propres attributs.
FDP (Foreign Data Providers) qui représente la proportion d'utilisation d'attributs "extérieurs" et utilisés dans très peu d'autres classes.
ATFD (Access to Foreign Data) qui représente la proportion de méthodes de la classe qui accèdent aux attributs directement ou via des accesseurs d'autres classes extérieures.

Cette méthode de détection est utilisée dans les outils iPlasma et inFusion.
D'autres outils comme JDeodorant, essayent de déplacer les méthodes dans des autres classes. Ainsi pour chaque méthode du programme, un algorithme va former une liste de classes candidates où il est possible de déplacer la méthode. Ensuite, pour chacun de ces candidats, un calcul de distance sera effectué ainsi qu'un calcul sur le nombre appel d'accesseurs.

==> Sur le nombre appel -> Le nombre d 'appels ?

A la fin, on sélectionne la classe dont la distance avec la méthode est minimale et dont les accès à ses données sont plus nombreuses qu'aux autres classes^[8]^[9].

==> A reformuler, manque de clarté et de cohérence syntaxique

Autre approche avec un outil nommé HIST basé sur l'analyse de commits, une méthode affectée par le Smell Feature Envy a tendance à changer plus fréquemment avec les méthodes des autres classes qu'avec celles de sa propre classe^[10].

==> Référence vers "commits"

Enfin, il existe également un plugin Eclipse permettant de détecter cette erreur.

==> Référence vers "Eclipse"

Ce greffon nommé Eclipse Metrics^[11] calcul un indice de jalousie maximal et dès que cet indice est dépassé, l'utilisateur est informé via un message d'avertissement.

==> Calcul -> Calcule

BLOB[modifier le code]

Cette erreur est l'impact direct de l'incapacité à concevoir correctement des architectures logicielles complexes dans un langage de programmation procédural.

=> Certains termes mériteraient d'être référencés via Wikipédia. Essayez de penser que cet article pourrait être lu par n'importe quel curieux.

En plus d'être totalement inélégante, le programme perd en vitesse d’exécution et la classe est difficilement maintenable. Il est possible de l'éviter en s'imposant les bonnes pratiques de développement suivantes :

Utiliser le paradigme Diviser pour mieux régner.
Créer des classes abstraites ou qui étendent d'autres classes.

Il n'y a pas de correction miracle pour un tel cas, il faut repenser son code afin de le factoriser. La taille de la classe n'est pas liée à cette erreur de conception. D'une manière générale, voici les corrections typiques :

Retirer les méthodes n'ayant aucuns impacts sur la classe en question et les replacer dans la classe impactée par l'appel de la méthode.

==> Aucuns impacts -> Aucun impact

Ainsi, dans la classe ci-dessous, la méthode afficher_pilote() devra être déplacer dans la classe Pilote...

==> Déplacer -> Déplacée

public class Avion {

   private Pilote pilote;

   ...

   public String afficher_pilote() {...}

}

Retirer les attributs présents illogiquement dans la classe et les placer dans les classes adaptées.

Ainsi, dans la classe ci-dessous, l'attribut matricule_pilote devra être déplacer dans la classe Pilote...

==> Déplacer -> Déplacée

public class Avion {

   private Pilote pilote;
   private String matricule_pilote;

   ...

}

Retirer les associations dont l’existence n'est pas nécessaire.

Ainsi, dans la classe ci-dessous, la référence pilote devra être déplacer dans la classe Equipage...

==> Déplacer -> Déplacée

public class Avion {

   private Equipage equipage;
   private Pilote pilote;

   ...

}

Pour la détection, Lanza et Marinescu propose la formule conditionnelle suivante reposant sur trois métriques^[12] :

==> Lanza et Marinescu propose -> Proposent

$WMC\geq 47\land ATFD>5\land TCC<\left({\frac {1}{3}}\right)$
Avec :

47 et 5, des valeurs fixées et expliquées dans leur ouvrage.
WMC (Weighted Method Count) qui représente la somme de la complexité statistique de toutes les méthodes dans une classe.
TCC (Tight Class Cohesion) qui représente le nombre relatif de méthodes accédant aux attributs.
ATFD (Access to Foreign Data) qui représente le nombre de classes externes qui accèdent aux attributs de la classe directement ou via des accesseurs.

Cette méthode de détection est utilisée dans les outils iPlasma et inFusion.

DECOR utilise des fiches de règles nommées "Rules Cards"^[13]. D'après les caractéristiques de ces "Rules Cards", un BLOB est une classe ayant un LCOM5 (un manque de cohésion de méthodes, Lack of Cohesion Of Methodes en anglais) supérieur à 20 et un nombre de méthodes et d'attributs supérieurs à 20. De plus, les classes sont identifiables par des noms suspects comme Process, Control, Manage, System etc...^[14]
Pour connaître le LCOM5 d'une classe, on utilise la formule ci dessous^[15]:
$LCOM5={\frac {(a-kl)}{(l-kl)}}$
Avec :

l, le nombre d'attributs
k, le nombre de méthodes
a, la somme du nombre d'attributs distincts accédés par chaque méthode dans une classe

D'autres outils comme JDeodorant essayent de décomposer la classe en plusieurs afin de déterminer si la classe est un BLOB^[16]. Cette décomposition s'effectue par clustering, s'il est possible de partitionner de manière optimale les méthodes dans différentes classes alors c'est un BLOB. Pour former les différents clusters, on utilise alors entre les membres (attributs, méthodes etc..) de la classe, la distance de Jaccard définie ainsi^[17]^[9] :
$Jaccard(E_{i},E_{j})=1-\left|{\frac {E_{i}\cap E_{j}}{E_{i}\cup E_{j}}}\right|$
Enfin, avec HIST, outil basé sur l'analyse de commits, on peut détecter un BLOB car c'est une classe qui change régulièrement dans le temps ^[18].

Long Parameter List[modifier le code]

Le code Smell Long Parameter List (longue liste de paramètres littéralement) survient dans les classes contenant une méthode ayant trop de paramètres.
Cette erreur est typiquement commise lors de la fusion de plusieurs algorithmes en un seul. Attention a ne pas factoriser le code trop vite! ==> a -> à Autre possibilité, lorsqu'un développeur essaye de rendre une classe trop paramétrable. Généralement, il est fort difficile de comprendre ces listes de paramètres tant qu'elles deviennent assez vite contradictoires et difficiles à utiliser concrètement.
Voici des exemples de corrections possibles :

Retirer les paramètres résultant d'appels de méthodes sur un autre objet, l'objet en question peut être placé dans le domaine de sa classe ou utilisé comme paramètre.

Par exemple, si les derniers paramètres de la fonction calcul() sont issus d'un objet Mesures :

public void calcul( ...., int x, int y, int z) {

    ...

}

On peut alors directement passer l'objet Mesure en paramètre.

public void calcul( ...., Mesures mesures) {

    ...

}

Regrouper les paramètres pouvant l'être et passer l'objet ainsi créé dans la méthode.

Si l'on reprend l'exemple précédent, lêle si les paramètres x, y et z sont totalement indépendants, on peut créer un objet pour réduire le nombre de paramètres.

==> lêle -> même ?

public void calcul( ...., int x, int y, int z) {

    ...

}

On peut alors directement passer ce nouveau objet créé par en paramètre.

==> Nouveau -> Nouvel

public Objet creer_objet(int x, int y, int z) {

    ...

}

public void calcul( ...., Objet valeurs) {

    ...

}

Pour ce qui est de la détection, il suffit de compter le nombre de paramètres d'une méthode !
Chaque outils de détection a son nombre maximum autorisé. Par exemple, PMD a pour valeur maximale 10 et Checkstyle 7^[19].

==> Outils -> Outil

Long Method[modifier le code]

Le code Smell Long Method (longue méthode littéralement) survient dans les classes contenant une méthode ayant trop d'instructions.
Cette erreur est généralement commise par les développeurs ne décomposant pas suffisamment leurs codes. Pour éviter de telles erreurs, un développeur peut adopter les mêmes principes de développement cités dans la partie sur le Duplicated Code : Travailler en TDD ou factoriser son code en partitionnant le code en petites méthodes.
Pour détecter ce code Smell, il ne suffit pas de compter le nombre de ligne de codes des méthodes. En effet, dans certains cas, il est réellement nécessaire d'avoir autant de codes quand il n'est pas fractionnable. On ne peut donc pas créer des moyens de détection comme pour le Long Parameter Method.

Mäntyla suggère d'utiliser pour la détection la complexité cyclomatique ainsi que les métriques d'Halstead^[20].

Cependant, certains outils détectent ce Smell uniquement en comptant le nombre de ligne de codes NLOC. C'est le cas de Checkstyle qui considère qu'une méthode est longue à partir de 150 lignes et PDM à partir de 100 lignes^[19].
JDeodorant utilise des techniques de tranchage pour déterminer si une méthode peut être scindée en plusieurs autres.

Large Class[modifier le code]

Le Smell Large Class (classe large littéralement) est une classe contenant trop de responsabilités. Cette erreur est souvent commise par le développeur débutant négligeant les principes de l'orienté objet.
La NASA Software Assurance Technology Center a publié les valeurs seuils recommandées pour éviter de créer une Large Class. Selon elle, une classe a trop de fonctionnalités quand l'une des conditions suivantes n'est pas valide ^[21] :

Le nombre de méthodes dans la classe est inférieur à 20
Le poids des méthodes par classe est inférieur à 100
Le nombre de méthodes et le nombre de méthodes invoquées par chacune de ces méthodes est inférieur à 100
Le nombre de classes référencées dans la classes est inférieur à 5

On peut aussi compter le nombre de lignes de la classe (souvent appelé NLOC pour number of lines of code) et le comparer à un maximum que l'on s'impose. Par exemple, PMD considère qu'une classe est large si elle contient plus de 1000 lignes de codes et Checkstyle 2000 lignes^[19].
Cependant, il est possible de faire des exceptions pour les classes contenant des interfaces graphiques pour l'utilisateur (GUI).
Pour corriger ce problème, il faut réduire les responsabilités de la classe en question en restructurant le code en différentes classes de faibles responsabilités. Outre le gain de clarté après la restructuration, la maintenance du programme sera plus aisée.

Outils existants[modifier le code]

Il existe de plus en plus d'outils de détection automatique de ces mauvaises pratiques de conception. Nous vous proposons une liste non exhaustive des principaux outils existants.

DECOR[modifier le code]

Proposé par Naouel Moha, DECOR^[22] pour Detection&Correction, est un outil qui consiste en la détection et la correction automatique des codes smells. Le processus est décomposé deux parties, DETEX et COREX, qui font la spécificité de cette méthode.

Tout d'abord, la détection est assuré par un ensemble de règles, qu'il faut spécifier à l'aide d'un langage de haut niveau.

Ensuite, l'utilisateur suggère ses restructurations de codes souhaitées, de nouveau grâce à l'utilisation du même langage.

Enfin, l'outil se charge d'analyser et corriger automatiquement les défauts dans le code, en se basant sur les règles décrites au préalable.

Cette méthode englobant à la fois la détection et la correction présente l'avantage d'automatiser l'ensemble du processus sans faire intervenir manuellement le développeur pour chaque correction détectée.

DECOR est aujourd'hui capable de détecter 19 codes smells différents parmi lesquels on trouve le Blob, Long Method ou Long Class par exemple.^[23]

Checkstyle[modifier le code]

voir Checkstyle

PDM[modifier le code]

voir pMD

inFusion[modifier le code]

inFusion est une solution commerciale clé en main à destination des développeurs et basé sur l'outil iPlasma.

Il présente l'avantage d'être un outil complet avec sa propre interface pour être utilisé de façon indépendante.

Il est capable de détecter plus de 20 codes smells parmi lesquels Duplicated Code, Blob, Long Method ou Long class.

inFusion gère également l'analyse de code Java, C ou C++.

JDeodorant[modifier le code]

Présenté sous la forme d'un plugin pour l'environnement de développement Eclipse^[24] développé par les équipes de l'Université Concordia au Canada et l'Université de Macédoine en Grèce.

L'outil qui s'utilise donc directement dans l'éditeur permet de détecter des codes smells et de proposer la réfactorisation appropriée.

Il est à ce jour capable de détecter 5 cas de codes smells, Feature Envy, Type-Checking, Long Method, Blob ou encore Duplicated Code.

JDeodorant^[25] possède plusieurs avantages, notamment :

Pré-évaluation des effets de chaque solution proposée

Guidage de l'utilisateur dans la compréhension des erreurs de conception.

Simplicité de l'outil, "one-click approach".

Stench Blossom[modifier le code]

Stench Blossom^[26] est un détecteur de codes Smells qui fournit un environnement interactif qui permet aux développeurs de visualiser rapidement les smells contenus dans leur code.
La rétroaction est synthétique et visuelle et offre des informations très détaillées sur l'origine de l'erreur sous la forme d'ensemble de pétales.
Plus l'erreur est important et plus la pétale est grande. Le développeur peut alors voir directement quelle erreur est la plus importante en regardant l'ensemble créé et corriger son code en conséquence.
Stench Blossom est un plugin Eclipse qui détecte 8 mauvaises odeurs dans des codes JAVA.

HIST[modifier le code]

HIST, pour Historical Information for Smell deTection ^[27], est un outil de détection de code smells apportant la particularité d'une approche basée sur l'historique d'un gestionnaire de versions, en plus de l'analyse statique de code habituelle.

La présence de problèmes de conceptions au sein d'un code source oblige les développeurs à adopter un comportement spécifique lors d'une modification du programme. Ces comportements, sont ensuite détectables grâce à l'historique du gestionnaire de versions. HIST propose donc de repérer ces réfactorisations particulières via la mise en place de patrons de détections spécifique à un code smells.

HIST prend en charge 5 codes smells parmi les plus connus, Divergent Change, Shotgun Surgery, Parallel Inheritance, Blob et Feature Envy.

Par exemple, la détection du code smell Blob par l'utilisation d'un historique se base sur le comportement de réfactorisation. En effet, quand une classe Blob est présente dans un programme, la probabilité que cette classe soit modifiée lors d'une réfactorisation est élevée. Il suffit alors de regarder dans le projet une classe qui est régulièrement modifiée dans un commit impliquant une autre classe^[28]. Comparativement à d'autres outils (notamment DECOR), Hist possède un taux de détection plus élevé^[29], cependant il nécessite également plus d'information que le seul code source. De plus, l'analyse de l'historique se présente comme une phase supplémentaire à l'analyse statique, la comparaison n'a donc d'intérêt tant les deux méthodes sont complémentaires.

↑ Refactoring: Improving the Design of Existing Code 1999, p. 63-73
↑ Refactoring: Improving the Design of Existing Code 1999, p. 63-64
↑ Refactoring: Improving the Design of Existing Code 1999, p. 66
↑ Refactoring: Improving the Design of Existing Code 1999, p. 65
↑ Refactoring: Improving the Design of Existing Code 1999, p. 65
↑ Refactoring: Improving the Design of Existing Code 1999, p. 63-64
↑ Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems 2007, p. 85-86
↑ Identification of Move Method Refactoring Opportunities 2009, p. 1-2
↑ ^{a et b} Automatic detection of bad smells in code: An experimental assessment 2012, p. 5
↑ Detecting Bad Smells in Source Code using Change History Information 2013, p. 4
↑ http://eclipse-metrics.sourceforge.net/descriptions/pages/FeatureEnvy.html
↑ Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems 2007, p. 80-81
↑ DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008, p. 43-45
↑ Anti-Pattern Detection: Methods, Challenges and Open Issues 2014, p. 3
↑ An Effort to Improve Cohesion Metric Using Inheritance 2013, p. 2
↑ Decomposing object-oriented class modules using an agglomerative clustering technique 2009, p. 4
↑ Anti-Pattern Detection: Methods, Challenges and Open Issues 2013, p. 4-5
↑ Detecting Bad Smells in Source Code using Change History Information 2013, p. 3
↑ ^{a b et c} Automatic detection of bad smells in code: An experimental assessment 2012, p. 6
↑ An experiment on subjective evolvability evaluation of object-oriented software: explaining factors and interrater agreement 2007, p. 7
↑ Looking for Patterns in Code Bad Smells Relations 2011, p. 2
↑ DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008
↑ DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008, p. 100
↑ « JDeodorant », sur Eclipse Plugins, Bundles and Products - Eclipse Marketplace (consulté le 6 décembre 2015)
↑ JDeodorant: Identification and Removal of Type-Checking Bad Smells 2009, p. 1-3
↑ Decomposing object-oriented class modules using an agglomerative clustering technique 2010
↑ HIST : Historical Information for Smell deTection 2013
↑ HIST : Historical Information for Smell deTection 2013, p. 270-271
↑ HIST : Historical Information for Smell deTection 2013, p. 274-275

[1] Refactoring: Improving the Design of Existing Code 1999, p. 63-73

[2] Refactoring: Improving the Design of Existing Code 1999, p. 63-64

[3] Refactoring: Improving the Design of Existing Code 1999, p. 66

[4] Refactoring: Improving the Design of Existing Code 1999, p. 65

[5] Refactoring: Improving the Design of Existing Code 1999, p. 65

[6] Refactoring: Improving the Design of Existing Code 1999, p. 63-64

[7] Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems 2007, p. 85-86

[8] Identification of Move Method Refactoring Opportunities 2009, p. 1-2

[:0-9] {a et b} Automatic detection of bad smells in code: An experimental assessment 2012, p. 5

[10] Detecting Bad Smells in Source Code using Change History Information 2013, p. 4

[11] ttp://eclipse-metrics.sourceforge.net/descriptions/pages/FeatureEnvy.html

[12] Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems 2007, p. 80-81

[13] DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008, p. 43-45

[14] Anti-Pattern Detection: Methods, Challenges and Open Issues 2014, p. 3

[15] An Effort to Improve Cohesion Metric Using Inheritance 2013, p. 2

[16] Decomposing object-oriented class modules using an agglomerative clustering technique 2009, p. 4

[17] Anti-Pattern Detection: Methods, Challenges and Open Issues 2013, p. 4-5

[18] Detecting Bad Smells in Source Code using Change History Information 2013, p. 3

[:1-19] {a b et c} Automatic detection of bad smells in code: An experimental assessment 2012, p. 6

[20] An experiment on subjective evolvability evaluation of object-oriented software: explaining factors and interrater agreement 2007, p. 7

[21] Looking for Patterns in Code Bad Smells Relations 2011, p. 2

[22] DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008

[23] DECOR : Détection et correction des défauts dans les systèmes orientés objet 2008, p. 100

[24] « JDeodorant », sur Eclipse Plugins, Bundles and Products - Eclipse Marketplace (consulté le 6 décembre 2015)

[25] JDeodorant: Identification and Removal of Type-Checking Bad Smells 2009, p. 1-3

[26] Decomposing object-oriented class modules using an agglomerative clustering technique 2010

[27] HIST : Historical Information for Smell deTection 2013

[28] HIST : Historical Information for Smell deTection 2013, p. 270-271

[29] HIST : Historical Information for Smell deTection 2013, p. 274-275

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

Codes Smells[modifier le code]

Exemples de codes smells[modifier le code]

Duplicated Code[2][modifier le code]

Feature Envy[3][modifier le code]

BLOB[modifier le code]

Long Parameter List[4][modifier le code]

Long Method[5][modifier le code]

Large Class[6][modifier le code]

Détection et correction de codes smells[modifier le code]

Moyens de détection[modifier le code]

Duplicated Code[modifier le code]

Feature Envy[modifier le code]

BLOB[modifier le code]

Long Parameter List[modifier le code]

Long Method[modifier le code]

Large Class[modifier le code]

Outils existants[modifier le code]

DECOR[modifier le code]

Checkstyle[modifier le code]

PDM[modifier le code]

inFusion[modifier le code]

JDeodorant[modifier le code]

Stench Blossom[modifier le code]

HIST[modifier le code]

Duplicated Code^[2][modifier le code]

Feature Envy^[3][modifier le code]

Long Parameter List^[4][modifier le code]

Long Method^[5][modifier le code]

Large Class^[6][modifier le code]